Skip to content

Conversation

@sarthak-19
Copy link
Contributor

Part of a polishing issue : #2317

Summary

This PR implements the transition animation duration setting that was previously added to the UI but wasn't functional. The duration setting now properly affects view transitions on both the frontend and WordPress admin area.

@codecov
Copy link

codecov bot commented Jan 4, 2026

Codecov Report

❌ Patch coverage is 5.66038% with 50 lines in your changes missing coverage. Please review.
✅ Project coverage is 69.39%. Comparing base (ce1b405) to head (07de264).
⚠️ Report is 226 commits behind head on trunk.

Files with missing lines Patch % Lines
plugins/view-transitions/includes/settings.php 3.84% 50 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##            trunk    #2321      +/-   ##
==========================================
+ Coverage   68.85%   69.39%   +0.54%     
==========================================
  Files          90       90              
  Lines        7612     7753     +141     
==========================================
+ Hits         5241     5380     +139     
- Misses       2371     2373       +2     
Flag Coverage Δ
multisite 69.39% <5.66%> (+0.54%) ⬆️
single 35.39% <0.00%> (-0.08%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@westonruter westonruter added the [Plugin] View Transitions Issues for the View Transitions plugin label Jan 4, 2026
@westonruter westonruter added this to the view-transitions n.e.x.t milestone Jan 4, 2026
@westonruter westonruter added the [Type] Enhancement A suggestion for improvement of an existing feature label Jan 4, 2026
@westonruter
Copy link
Member

Comment from @sarthak-19 in Slack:

I raised a draft PR because currently I was unsure of what more are we expecting to be delivered in this task for polishing, since the issue mentioned of Add support for customizing transition animation duration
But this was already added in the UI as well.
What I did for potential polishing items are :

  1. Added validation bounds - Duration is now clamped between 100ms and 5000ms with proper input validation
  2. Applied duration to admin - Admin view transitions now also respect the duration setting
  3. Added real-time preview - The seconds equivalent updates dynamically as you type in the > milliseconds field.
  4. Exposed in REST API - Added default_transition_animation_duration to the REST API schema
  5. Added unit tests - Tests for duration sanitization, clamping, and the injection function

?>
<style>
@view-transition { navigation: auto; }
::view-transition-group(*) { animation-duration: <?php echo esc_html( (string) $duration_seconds ); ?>s; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

esc_attr is probably more appropriate here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, neither is appropriate, as I've come to find. The contents of STYLE are the same as SCRIPT in that they are “raw text”. Entities are not processed.

In any case, since the value is an integer anyway, we can ensure proper escaping via:

Suggested change
::view-transition-group(*) { animation-duration: <?php echo esc_html( (string) $duration_seconds ); ?>s; }
::view-transition-group(*) { animation-duration: <?php echo (int) $duration_seconds; ?>s; }

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, that is best. esc_html felt too broad, the int cast is perfect.

?>
<input
type="number"
id="<?php echo $field_id; ?>"
Copy link
Member

@westonruter westonruter Jan 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
id="<?php echo $field_id; ?>"
id="<?php echo esc_attr( $args['label_for'] ); ?>"

Copy link
Contributor Author

@sarthak-19 sarthak-19 Jan 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to use esc_attr( $args['label_for'] ) multiple times that's why I used $field_id variable like :

$field_id = esc_attr( $args['label_for'] );

Is there something wrong with this approach ?
Since I'm using field_id like :

		<span class="description">
			<?php
			printf(
				/* translators: %s: duration in seconds wrapped in a span for dynamic update */
				esc_html__( 'ms (%s)', 'view-transitions' ),
				'<span id="' . $field_id . '-seconds">' . esc_html( (string) $seconds ) . 's</span>'
			);
			?>
		</span>
		<?php
		wp_print_inline_script_tag(
			sprintf(
				'document.getElementById( %s ).addEventListener( "input", function( e ) { document.getElementById( %s ).textContent = ( parseInt( e.target.value, 10 ) / 1000 ) + "s"; } );',
				wp_json_encode( $field_id ),
				wp_json_encode( $field_id . '-seconds' )
			)
		);
		

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, better to not do that. It's better to always use an escaping function wherever a variable is being printed. While there would be no vulnerability the way you have it now, at some point in the future something could change to that variable to make it vulnerable. Also, every time a developer looks at the printing they'd have to go up to make sure it had been escaped.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ohh okay, make sense, I'll keep this in mind moving forward, I was just trying to follow DRY design principle!!

printf(
/* translators: %s: duration in seconds wrapped in a span for dynamic update */
esc_html__( 'ms (%s)', 'view-transitions' ),
'<span id="' . $field_id . '-seconds">' . esc_html( (string) $seconds ) . 's</span>'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
'<span id="' . $field_id . '-seconds">' . esc_html( (string) $seconds ) . 's</span>'
'<span id="' . esc_attr( $args['label_for'] . '-seconds' ) . '">' . esc_html( (string) $seconds ) . 's</span>'

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, same doubt : #2321 (comment)

Comment on lines 525 to 528
/* translators: %s: duration in seconds wrapped in a span for dynamic update */
esc_html__( 'ms (%s)', 'view-transitions' ),
'<span id="' . $field_id . '-seconds">' . esc_html( (string) $seconds ) . 's</span>'
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure we need the seconds? Can't we just have the milliseconds?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can have, but as a part of polishing feature it can be a simple yet effective thing from end user perspective don't you think ?

I mean I'm open to discussion here, can remove if it's overkill.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it can be removed. The UI here is not going to be proposed for core, so it's for power users of the plugin. They already have to be comfortable with CSS selectors, so they should be comfortable with milliseconds as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure then I'll remove this and push the updated changes.

Comment on lines 532 to 538
wp_print_inline_script_tag(
sprintf(
'document.getElementById( %s ).addEventListener( "input", function( e ) { document.getElementById( %s ).textContent = ( parseInt( e.target.value, 10 ) / 1000 ) + "s"; } );',
wp_json_encode( $field_id ),
wp_json_encode( $field_id . '-seconds' )
)
);
Copy link
Member

@westonruter westonruter Jan 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per above, I don't think we need this.

Suggested change
wp_print_inline_script_tag(
sprintf(
'document.getElementById( %s ).addEventListener( "input", function( e ) { document.getElementById( %s ).textContent = ( parseInt( e.target.value, 10 ) / 1000 ) + "s"; } );',
wp_json_encode( $field_id ),
wp_json_encode( $field_id . '-seconds' )
)
);

Comment on lines 501 to 502
} elseif ( 'number' === $type ) {
$seconds = (int) $value / 1000;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a general field output for number but it presumes the number value is going to be seconds or time. That doesn't seem ideal. Note how the checkbox condition above is agnostic to what the setting is for.

Comment on lines 511 to 512
min="<?php echo esc_attr( (string) PLVT_MIN_ANIMATION_DURATION ); ?>"
max="<?php echo esc_attr( (string) PLVT_MAX_ANIMATION_DURATION ); ?>"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These should come from the $args

@sarthak-19 sarthak-19 marked this pull request as ready for review January 18, 2026 16:25
@github-actions
Copy link

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @sarthak.jaiswal@rtCamp.com.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: sarthak.jaiswal@rtCamp.com.

Co-authored-by: adamsilverstein <adamsilverstein@git.wordpress.org>
Co-authored-by: westonruter <westonruter@git.wordpress.org>
Co-authored-by: sarthak-19 <sarthak8858@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

exit; // Exit if accessed directly.
}


Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

@westonruter

This comment was marked as resolved.

@westonruter
Copy link
Member

Another polishing idea: there could be validation added to the input fields for the CSS selectors. Maybe this would be as simple as a pattern attribute added to each with a regex that would roughly match a valid regex. A more sophisticated validation would be to use JS to put the selector into a call to document.querySelector. If it errors, then we'd know the selector is invalid and we could call setCustomValidity() on the input element. I don't think there would be any security issue introduced by running user input into a JS function like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Plugin] View Transitions Issues for the View Transitions plugin [Type] Enhancement A suggestion for improvement of an existing feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants